feat(core): every controller reads as the standard gamepad (PRD-880) - #664

A game binds W3C standard indices and nothing else: `buttons: [0]` is the
south face button on an Xbox pad, an 8BitDo and a Steam Deck.

- core: `gamepad-mappings.ts` normalizes a pad the browser reports unmapped
  from one SDL_GameControllerDB row per vendor:product, `InputMap` owns the
  two pad conventions every game repeated — a radial dead zone (0.2, the
  stock Enhanced Input value, rescaled so full tilt is still 1) and the pad
  that last moved, so an idle wheel in slot 0 cannot steal the input. An
  unmapped pad is ignored and reported once as `TN_GAMEPAD … unmapped`
  rather than read with raw indices.
- runtime-native: one SDL3 -> standard table, `fillStandardPad`, replaces
  the two copies that disagreed about axes and buttons, so the legacy host
  and the owned engine player cannot report different counts or indices.
- playtest: a `gamepad` step scripts a standard pad through
  `navigator.getGamepads`, announces it the way a real pad appears, and
  survives a startup reload.
- search and conventions: InputMap carries the controller aliases and
  situations, and every kit's AGENTS.md indexes the `gamepad` convention.

Proofs: input.spec.ts (dead zone, active pad, three device rows),
ctest gamepad_standard (both entry points identical), search.spec.ts,
kit-conventions.spec.ts, and the platformer kit driven in a browser by both
new scenarios — `movementDelta` x 28.87, `jumps` 0 -> 1, and 0 movement at a
0.1 stick.

Every phase box and AC-1 are ticked and proven in the previous commit; the
only work left is the owner's read of one official Xbox pad, the 8BitDo
Ultimate C 2.4G and a Steam Deck, which settles the two vendor:product rows
the web table carries from SDL_GameControllerDB.

…stops allocating

Round 2 of review of PR #664: the level-based hand-over still let a pad that
claimed the slot while the player was idle keep it for the session, because a
worn stick resting past the dead zone reports input on every tick.

- Hand-over is now a rising edge (`#padHadInput` per slot, preallocated): a pad
  whose input goes from idle to active takes the slot, the pad in use keeps it
  while idle so its releases are read, and a pad that disappeared or turned
  unmapped hands over to whichever pad is held. `input.spec.ts` locks both
  orders: a held pad defended against a drifter, and the player taking the slot
  back from a drifter that claimed it at boot.
- The `TN_GAMEPAD` key is cached per slot:id (`#padKeys`/`#padKeyIds`), so a
  tick no longer builds a template literal twice for the active pad — the same
  promise the vendor:product cache now keeps.
- The SDL row comments name the GUID form each row came from instead of calling
  them all Linux entries, and the mutable `gamepadDeadZone` documents what a
  value it cannot honour reads as (raw axes).

Re-proved: typecheck, 282 focused tests, `ctest gamepad_standard`,
`pnpm ci:fast`, and the platformer kit in a browser (x delta 28.87,
jumps 0 -> 1, 0 movement at a 0.1 stick).

Round 3 of review of PR #664: the pad-wide rising edge still let a stick
jittering across the dead zone take the slot in the middle of a move, and the
player could not take it back with a button because their pad already had
input, so no pad-level edge fired.

- A pad now claims on a new button press (a per-slot mask, preallocated) or on
  a stick travelling past half tilt; a stick resting past the dead zone or
  jittering across it rescales to about 0.01 and claims nothing. A button still
  reclaims while the player is holding the stick still.
- `input.spec.ts` locks the case: a jittering drifter never steals from a held
  pad, and a button press reclaims. The gentle re-cross no longer steals; a
  deliberate move does.
- The convention row, its reference page and the `InputMap` tags state the
  claim rule, so the words a kit reads match the code.
- Proving AC-1 surfaced a real flake in the scaffolder: two config loads in the
  same millisecond in one process picked the same temp filename, and the first
  one's unlink deleted the second one's file (TN_CONFIG_LOAD_FAILED). `vite`
  resolves its config twice through `resolveConfig`'s Promise.all, so the
  template lane and CI's drift lane hit it intermittently. A sequence number
  now distinguishes them.

Re-proved: typecheck, 283 focused tests, `pnpm ci:fast`, `ctest
gamepad_standard`, the config spec (117), and the platformer kit in a browser
(x delta 28.87, jumps 0 -> 1, 0 movement at a 0.1 stick).

…o claim-rule gaps

Round 4 of review of PR #664 accepted the gamepad work and blocked on evidence:
the config temp-name fix had no red-green test, and the PR body cited the
unchanged `config.spec.ts` as if it did.

- `configTempName` is now a named export, and a spec asserts two loads that
  share a pid and a millisecond get different paths. Dropping the sequence
  fails it deterministically (checked); a concurrent-load spec covers the
  loader under `Promise.all`, and I confirmed first-hand that the race itself
  does not reproduce under a stubbed clock, so the invariant is the lock.
- Two claim-rule gaps the same review named: slots past the end of a shrinking
  source are forgotten, so a pad that later connects there starts from rest;
  and a slot that merely held the input without claiming is unowned, so a slow
  walk on a later pad is read instead of being hidden by an idle slot 0. One
  spec each.
- The PRD Decision that still described the round-2 rule is rewritten to the
  claim rule with all three rounds' holes and the specs that lock them.

Re-proved: typecheck, 403 focused tests, `ctest gamepad_standard`, `pnpm
ci:fast`, and the platformer kit in a browser (x delta 28.87, jumps 0 -> 1,
0 movement at a 0.1 stick).

…ming a lock it is not

Round 5 of review of PR #664: the code was accepted, two evidence claims were
not.

- The shrinking-source fix had no spec, though the PR said "one spec each".
  The new spec shrinks the source for a tick and then puts a different pad in
  the emptied slot already holding button 0; without the forgetting it fails
  ("expected false to be true"), and an owned idle slot 0 keeps the input.
- The concurrent-load spec was titled and commented as the lock for the
  temp-name collision, and it is not one: under a frozen clock the second
  `import()` is served from the module cache, so it passes without the suffix.
  `configTempName` is the lock; the loader spec now says it is loader coverage.
- The PRD's Decision history is corrected to the three rules as they shipped
  (level, then pad-wide edge, then the per-control claim), and names the
  reused-slot spec.

Re-proved: typecheck, 404 focused tests, `pnpm ci:fast`, `ctest
gamepad_standard`, and the platformer kit in a browser (x delta 28.87,
jumps 0 -> 1, 0 movement at a 0.1 stick).

The two nits the authorising review left: the mermaid node said 'active pad:
last with input' and ordered it before the dead zone, and the reused-slot
spec's comment credited slot 1 with the first claim when the lowest slot wins.
Comment and diagram only; no behaviour changes.

…#664)

The verdict otherwise exists only in a session transcript. What the gate
covered, what each round found, and what it still leaves unverified — CI's
board, the full native build, and the owner's device read — so the PRD's
BLOCKED status is readable on its own.

The physical read the PRD was blocked on, done on the device itself.

- The kernel reports `2dc8:3016`, which SDL 3.2.30 does not carry under any
  name, and Chromium reports `mapping: ""` with 15 buttons and 8 axes for it —
  so the pad was ignored on the web ("unmapped") and every binding it touched
  fired the wrong action or nothing.
- The row is built from the kernel's evdev order, cross-checked against presses
  on the pad: A b0, B b1, X b3, Y b4, LB b6, RB b7, LT b8 + axis a5, RT b9 +
  axis a4, Select b10, Start b11; left stick a0/a1, right stick a2/a3. The
  owner's browser now logs `TN_GAMEPAD {… "mapping":"table"}` and a left-stick
  push reads `move: [0, -1]` through the real InputMap.
- Two limits the same read found, recorded rather than papered over: the stick
  clicks reach the kernel as `BTN_TL2` (the left trigger's digital button), so
  no browser can report them as separate controls and b13/b14 stay inert; and
  the extra C/Z buttons have no standard slot.
- `input.spec.ts` "maps every control the 8BitDo Ultimate C 2.4G actually
  sends" asserts each standard slot against its raw index, and that every other
  action stays dark, so a wrong slot fails by name.

Re-proved: typecheck, 327 focused tests, `pnpm ci:fast`, and the PRD's
Blocked-on now names only the Xbox pad and the Steam Deck.

…ured vs derived

Round 7 of review of PR #664 blocked the device row on two precision points,
both fair.

- The spec now pins the right stick in both directions (`lookX` on a2, `lookY`
  on a3), so a row with the two swapped — or with the right stick missing —
  fails one of the pairs. It previously only asserted that the right stick was
  not movement.
- The row comment and the PRD no longer claim the trigger sides were read per
  frame in the page. They are derived from the kernel: pressing LT emitted
  `ABS_BRAKE` (10) and RT `ABS_GAS` (9), and axes arrive in ascending ABS order
   — the rule the two sticks confirm — so left is a5 and right a4, matching
  SDL's 8BitDo rows. The buttons, both sticks and both triggers' digital codes
  were measured directly.
- The stick-click caveat is scoped to Linux on this unit, where it was observed.

Re-proved: typecheck, 60 input specs, `pnpm ci:fast`, docs links.

… not measured

Round 9 of review of PR #664 caught the same measured-versus-derived slip as the
triggers: the row comment and the PRD said clicking the sticks "confirms"
left = 13 and right = 14, but the observation was both raw buttons in one frame,
which cannot separate the sides. The indices are measured; the sides follow the
kernel's BTN_THUMBL (317) before BTN_THUMBR (318) order, the same derivation the
triggers use. Comment, spec comment and PRD all say so now.

No behaviour change; the mapping string is untouched.